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Foreword 

This Technical Specification has been produced by the 3 rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The security of MBMS provides different challenges compared to the security of services delivered over point-to-point 
services. In addition to the normal threat of eavesdropping, there is also the threat that it may not be assumed that valid 
subscribers have any interest in maintaining the privacy and confidentiality of the communications, and they may 
therefore conspire to circumvent the security solution (for example one subscriber may publish the decryption keys 
enabling non-subscribers to view broadcast content). Countering this threat requires the decryption keys to be updated 
frequently in a manner that may not be predicted by subscribers while making efficient use of the radio network. 
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1 Scope 

The Technical Specification covers the security procedures of the Multimedia Broadcast/Multicast Service (MBMS) for 
3GPP systems (UTRAN and GERAN). MBMS is a 3GPP system network bearer service over which many different 
applications could be carried. The actual method of protection may vary depending on the type of MBMS application. 



2 References 

The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1". 

[3] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and Functional 
Description". 

[4] 3GPP TS 33.102: "3G Security; Security Architecture". 

[5] 3GPP TS 22.246: "MBMS User Services". 

[6] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping 
Architecture". 

[7] 3GPP TS 3 1 . 102: "Characteristics of the USIM application". 

[8] IETF RFC 2617 "HTTP Digest Authentication". 

[9] IETF RFC 3830 "MIKEY: Multimedia Internet KEYing" 

[10] IETF RFC 1982 "Serial Number Arithmetic". 

[II] IETF RFC 37 1 1 "Secure Real-time Transport Protocol" . 
[12] 3GPP TS 43.020: "Security related network functions". 

[13] 3GPP TS 26.346: "Multimedia Broadcast/Multicast Service; Protocols and Codecs". 

[14] 3GPP TS 33.210: "Network domain security; IP network layer security". 

[15] OMA-DRM-DCF-v2_0: "OMA DRM Content Format", www.openmobilealliance.org 

[16] IETF internet draft: "The Key ID Information Type for the General Extension Payload in MIKEY" 

<draft-carrara-newtype-keyid-00.txt>. 



ETSI 



3GPP TS 33.246 version 6.1.0 Release 6 



7 



ETSI TS 133 246 V6.1 .0 (2004-12) 



3 Definitions, abbreviations and conventions 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. 
For the definitions of MBMS User Service refer to TS 22.246 [5]. 
MBMS download session: See TS 26.346 [13]. 
MBMS streaming session: See TS 26.346 [13]. 

MRK = MBMS Request Key: This key is to authenticate the UE to the BM-SC when performing key requests etc. 

MSK = MBMS Service Key: The MBMS Service key that is securely transferred (using the key MUK) from the BM- 
SC towards the UE. The MSK is not used directly to protect the MBMS User Service data (see MTK). 

MTK = MBMS Traffic Key: A key that is obtained by the UICC or ME by calling a decryption function MGV-F with 
the MSK. The key MTK is used to decrypt the received MBMS data on the ME. 

MUK = MBMS User Key: The MBMS user individual key that is used by the BM-SC to protect the point to point 
transfer of MSKs to the UE 

NOTE: The keys MSK and MUK may be stored within the UICC or the ME depending on the UICC capabilities. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



MBMS 


Multimedia Broadcast/Multicast Service 


MGV-F 


MBMS key Generation and Validation Function 


MGV-S 


MBMS key Generation and Validation Storage 


MRK 


MBMS Request Key 


MSK 


MBMS Service Key 


MSK_C 


Confidentiality key derived from key MSK 


MSK_I 


Integrity key derived from key MSK 


MTK 


MBMS Traffic Key 


MUK 


MBMS User Key 


MUK_C 


Confidentiality key derived from key MUK 


MUK_I 


Integrity key derived from key MUK 


NAF 


Network Application Function 



3.4 Conventions 

All data variables in this specification are presented with the most significant substring on the left hand side and the 
least significant substring on the right hand side. A substring may be a bit, byte or other arbitrary length bitstring. 
Where a variable is broken down into a number of substrings, the leftmost (most significant) substring is numbered 0, 
the next most significant is numbered 1, and so on through to the least significant. 



4 MBMS security overview 
4.1 MBMS security architecture 

MBMS introduces the concept of a point-to-multipoint service into a 3GPP system. A requirement of a multicast 
service is to be able to securely transmit data to a given set of users. In order to achieve this, there needs to be a method 
of authentication, key distribution and data protection for a multicast service. 
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Figure 4.1 : MBMS security architecture 

Figure 4. 1 gives an overview of the network elements involved in MBMS from a security perspective. Nearly all the 
security functionality for MBMS (beyond the normal network bearer security) resides in either the BM-SC or the UE. 

The Broadcast Multicast - Service Centre (BM-SC) is a source for MBMS data. It could also be responsible for 
scheduling data and receiving data from third parties (this is beyond the scope of the standardisation work) for 
transmission. It is responsible for generating and distributing the keys necessary for multicast security to the UEs and 
for applying the appropriate protection to data that is transmitted as part of a multicast service. The BM-SC also 
provides the MBMS bearer authorisation for UEs attempting to establish multicast bearer. 

The UE is responsible for receiving or fetching keys for the multicast service from the BM-SC and also using those 
keys to decrypt the MBMS data that is received. 

MBMS imposes the following requirements on the MBMS capable elements: 

- a UICC that contains MBMS key management functions shall implement GBA_U; 

- a ME that supports MBMS shall implement GBA_U and GBA_ME, and shall be capable of utilising the MBMS 
key management functions on the UICC as well as providing key management functions itself; 

- a BM-SC shall support using GBA_U keys to enable UICC key management. 

4.1 A Granularity of MBMS security 

An MBMS User Service is composed of one or more MBMS Streaming Sessions and/or MBMS Download Sessions as 
defined in TS 26.346 [13]. MBMS streaming/download sessions may be transported over one or more MBMS 
Transport Services. Transport Services are defined in TS 23.246 [3]. MBMS security is used to protect MBMS 
streaming/download sessions. As such MBMS security is Transport Service independent, in particular, it is independent 
on whether it is carried over point-to-point or MBMS Bearer. 

4.2 Key management overview 

The BM-SC controls the use of the MBMS Service Keys (MSKs) to secure the different MBMS Streaming/Download 
Sessions that make up the MBMS User Service. The MSKs are not directly used to secure the MBMS 
Streaming/Download Sessions, but they are used to protect the delivery of MBMS Transport Keys (MTKs), which are 
used to secure the MBMS Streaming/Download Sessions, as specified within clauses 6.5 and 6.6. MSKs and MTKs are 
managed at the MBMS User Service Level. 

There shall be only one MSK and MTK in use within one Key Group ID. I.e. parallel use of two or more MSKs (with 
different MSK IDs) or MTKs (with different MTK IDs) within a Key Group ID shall not be allowed. 

The use of the same MTK (this implies also the same MSK) with two different transport services (or user services) 
should be avoided. 

NOTE 1 : This is to avoid synchronization problems in the UE when a new MTK is taken into use in the traffic, i.e. 
if the MTK is not changed synchronously in the traffic flows the UE would discard the traffic with 
smaller MTK ID. 

According to TS 22.246 [5] there exist MBMS User Services with shared and non-shared Transport Services. It shall be 
possible for MBMS User Services to share one or more MSKs for the shared Transport Services with other MBMS 
User Services. 

NOTE 2: While sharing MSKs among different MBMS User Services, care shall be taken that the Users are not 
given access to data that they are not entitled to. 
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5 MBMS security functions 

5.1 Authenticating and authorizing the user 

A UE is authenticated and authorised in the following situations when participating in an MBMS User Service. That is: 

when the UE performs User Service joining (or leaving ) on the application level; 
Editor's Note: The final decision on application level join procedures relies of work in SA4. 

when the UE establishes (or releases) the MBMS bearer(s) to receive an MBMS User Service; 

when the UE requests and receives MSKs for the MBMS User Service; 

when the UE performs post delivery procedures (e.g. point to point repair service). 
Editor's Note: The final decision on post delivery procedures relies of work in SA4. 
NOTE: The list above does not reflect the order of authentications. 

5.2 Key management and distribution 

Like any service, the keys that are used to protect the transmitted data in a Multicast service should be regularly 
changed to ensure that they are fresh. This ensures that only legitimate users can get access to the data in the MBMS 
service. In particular frequent re-keying acts as a deterrent for an attacker to pass the MBMS keys to others users to 
allow those other users to access the data in an MBMS service. 

The BM-SC is responsible for the generation and distribution of the MBMS keys to the UE. A UE has the ability to 
request a key when it does not have the relevant key to decrypt the data. This request may also be initiated by a message 
from the BM-SC to indicate that a new key is available. 

5.3 Protection of the transmitted traffic 

The traffic for a particular MBMS service may require some protection depending on the sensitivity of the data being 
transmitted (e.g. it is possible that the data being transmitted by the MBMS service is actually protected by the DRM 
security method and hence might not require additional protection. However, MBMS protection is independent of DRM 
protection). If this protection is required, it will be either confidentiality and integrity or confidentiality only, or 
integrity only. The protection is applied end-to-end between the BM-SC and the UEs and will be based on a symmetric 
key shared between the BM-SC and the UEs that are currently accessing the service. The actual method of protection 
specified may vary depending on the type of data being transmitted, e.g. media streaming application or file download. 

NOTE: When MBMS data is received over a point-to-point MBMS radio bearer, it would be ciphered between 
the BM-SC and UE and may also ciphered over the radio interface. This "double ciphering" is 
unnecessary from a security point of view and hence the decision of whether or not to apply radio 
interface ciphering to a point-to-point MBMS radio bearer is outside the scope of this specification. 



6 Security mechanisms 
6.1 Using GBA for MBMS 

TS 33.220 [6] (Generic Bootstrapping Architecture) is used to agree keys that are needed to run an MBMS Multicast 
User service. 

Before a user can access an MBMS User service, the UE needs to share GBA-keys with the BM-SC. If no valid GBA- 
keys are available at the UE, the UE shall perform a GBA run with the BSF of the home network as described within 
clause 5 of TS 33.220 [6]. The BM-SC will act as a NAF (Network Application Function) according to TS 33.220 [6]. 
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The MSKs for an MBMS User service shall be stored on either the UICC if the UICC is capable of MB MS key 
management or the ME if the UICC is not capable of MBMS key management. 

Storing the MSKs on the UICC requires a UICC that contains the MBMS management functions. 

As a result of a GBA_U run, the BM-SC will share a key Ks_ext_NAF with the ME and share a key Ks_int_NAF with 
the UICC. This key Ks_int_NAF is used by the BM-SC and the UICC as the key MUK (MBMS User Key) to protect 
MSK (MBMS Service Key) deliveries to the UICC as described within clause 6.3. The key Ks_ext_NAF is used as the 
key MRK (MBMS Request Key) within the protocols as described within clause 6.2. 

A run of GBA_ME results in the BM-SC sharing a key Ks_(ext)_NAF with the ME. This key Ks_(ext)_NAF is used by 
the BM-SC and the ME to derive the key MUK and the key MRK. The key MUK is used to protect MSK deliveries to 
the ME as described within clause 6.3. The key MRK is used to authenticate the UE towards the BM-SC within the 
protocols as described within clause 6.2. 

The MUK is identified by the combination of B-TID and NAF-ID and the MRK is defined by B-TID, where B-TID and 
NAF-ID are defined as specified in TS 33.220 [6]. 

For ME based key management: 

- All MBMS keys (MUK, MRK, MSK and MTK) shall be deleted from the ME when a different UICC is 
inserted. Therefore the ME needs to store in non-volatile memory the last inserted UlCC-identity to be able to 
compare that with the used UlCC-identity at UICC insertion and power on. 

- All MBMS keys (MRK, MSK and MTK) may be deleted from the ME when the ME is powered down. If the 
ME does not delete the MBMS keys at power down then the MBMS keys need to be stored in non-volatile 
memory. The ME should store the MUKs in non-volatile memory in order to be able to authenticate the first 
MIKEY message of a push solicited pull procedure (see clause 6.3.2.2.4). 

NOTE: If the ME deletes the MSK at power down, then the MBMS client would need to request MSK to the 
BM-SC and may need to run GBA to reconvene an MBMS session. 

6.2 Authentication and authorisation of a user 

Editor's Note: The exact details on how to derive the keys MRK and MUK from the GBA keys are for ffs. 

Editor's Note: According to S3-040212, SA4 has a working assumption to use HTTP as the transport protocol but 
this is only agreed for the download repair service. 

6.2.1 Authentication and authorisation in application level joining 

When the user wants to join (or leave) an MBMS user service, it shall use HTTP digest authentication RFC 2617 [8] for 
authentication. HTTP digest is run between BM-SC and ME. The MBMS authentication procedure is based on the 
general user authentication procedure over Ua interface that is specified in clause "Procedures using the bootstrapped 
Security Association" in TS 33.220 [6]. The BM-SC will act as a NAF according to TS 33.220 [6]. 

The following adaptations apply to HTTP digest: 

the transaction identifier as specified in TS 33.220 [6] is used as username; 

- MRK (MBMS Request Key) is used as password; 

the joined MBMS user service is specified in client payload of HTTP Digest message. 

Editor's Note: The contents of the client payload are FFS and may require input from TSG SA WG4. The final 
decision on application level join and leave procedures relies of work in S A4. 
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6.2.2 Authentication and authorisation in MBMS bearer establishment 

The authentication of the UE during MBMS bearer establishment relies on the authenticated point-to-point connection 
with the network, which was set up using network security described in TS 33.102 [4] or TS 43.020 [12]. Authorisation 
for the MBMS bearer establishment happens by the network making an authorisation request to the BM-SC to ensure 
that the UE is allowed to establish the MBMS bearer(s) corresponding to an MBMS User Service (see TS 23.246 [3] for 
the details). As MBMS bearer establishment authorisation lies outside the control of the MBMS bearer network (i.e. it is 
controlled by the BM-SC), there is an additional procedure to remove the MBMS bearer(s) related to a UE that is no 
longer authorised to access an MBMS User Service. 

6.2.3 Authentication and authorisation in MSK request 

When the UE requests MSK(s), the UE shall be authenticated with HTTP digest as in clause 6.2.1. 

6.2.4 Authentication and authorisation in post delivery procedures 

When the UE requests post delivery procedures, the UE shall be authenticated with HTTP digest as in clause 6.2.1. 

6.3 Key update procedures 

Editor's Note: The contents of the http client payloads are FFS and may require input from TSG SA WG4. 

6.3.1 General 

In order to protect an MBMS User service, it is necessary to transfer both MSKs and MTKs from the BM-SC to the UE. 
Clause 6.3.2 describes the possible procedures for transferring MSKs, while clause 6.3.3 deals with the transfer of 
MTKs. 

6.3.2 MSK procedures 
6.3.2.1 MSK identification 

Every MSK is uniquely identifiable by its Key Domain ID MSK ID 
where 

Key Domain ID = MCC II MNC and is 3 bytes long. 

MSK ID is 4 bytes long and with byte and 1 containing the Key Group part, and byte 2 and 3 containing the 
Key Number part. The Key Number part is used to distinguish MSKs that have the same Key Domain ID and 
Key Group part. Key Group part is used to group keys together in order to allow redundant MSKs to be deleted. 
The MSK ID is carried in the extension payload of MIKEY extension payload. 

NOTE: It needs to be ensured that the Key Group parts are unique within an operator, i.e. two BM-SCs within an 
operator shall not use the same Key Group value. 

If the UE receives an MSK and already contains two other MSKs under the same Key Domain ID and Key Group part, 
then the UE shall delete the older of these two MSKs. 

Editor's Note: The handling of MSKs may need some enhancement to cover download services, where the MSK is 
fetched after the UE has received the encrypted data. 
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6.3.2.2 MSK retrieval procedures 



6.3.2.2.1 Basic MSK retrieval procedure 

When a UE detects that it needs the MSK(s) for a specific MBMS User service, the UE should try to get the MSKs that 
will be used to protect the data transmitted as part of this User Service. In the MSK request the UE shall list the MSK 
IDs for which the UE needs the MSK(s). 

The basic MSK retrieval procedure is a part of different other procedures, e.g.: 

initiation of key management when the UE has joined the MBMS user service; 

retrieval of MSK(s) when the UE has missed a key update procedure e.g. due to being out of coverage. 
- BM-SC solicited pull. 



UE BM-SC 

HTTP POST (List of MSK IDs) 
► 

HTTP 401 WWW-Authenticate 

(digest challenge) 
-< 

HTTP POST Authorization request 
(digest response) (List of MSK IDs) 



HTTP 200 OK Authentication-Info 

■4 



MIKEY (v1SK)/UDP 
< 



MIKEY ACK/UDP 
► 

Figure 6.1 : Basic MSK retrieval procedure 

The communication between the UE and the BM-SC is authenticated and integrity protected with HTTP Digest as 
described in clause 6.2.1 of this specification. 

The UE requests for the MSKs WITH the HTTP POST message. The following information is included in the HTTP 
message. 

key identification information: a list of MSK IDs. 

NOTE: When the Key Number part of the MSK ID is set to 0x0, this means the current MSK, see clause 6.3.2. 1 . 

Editors' Note: The exact syntax of the HTTP request message, e.g. possible XML schema of the request parameters 
in the client payload and its MIME type are to be specified in stage 3. 

The BM-SC authenticates the UE with HTTP Digest using the keys received from GBA as described in clause 6.2.1 and 
verifies that the subscriber is authorized to receive the MSKs for this service. 

If the authentication is successful then the BM-SC sends a HTTP 200 OK message with Authentication-Info header. If 
the authentication fails then the BM-SC resends HTTP 401 Authorization required message with the WWW- 
Authenticate header. 

Editors' Note: The exact syntax of the HTTP response message, e.g. possible XML schema of the success or failure 
parameters in the client payload and its MIME type are to be specified in stage 3. 
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The UE checks the validity of the HTTP response message. If the message indicated failure, the UE may retry or leave 
the User Service. 

If the HTTP procedure above resulted to success, the BM-SC initiates MIKEY message procedures over UDP 
transporting the requested MSKs to the UE. 

If it was requested by the BM-SC, the UE sends a MIKEY acknowledgement message to the BM-SC. 

If the UE fails to get hold of the MSK or receives no confirmation that no updated MSK is necessary or available at this 
time, then, unless the UE has a still-valid, older MSK, the UE shall leave the MBMS user service. 

6.3.2.2.2 Initiation of key management 

When a UE has received User Service information via User Service Discovery / Announcement procedures describing a 
MBMS User Service and the user has triggered the activation of that User Service, the UE should try to get the MSK(s) 
that will be used to protect the data transmitted as part of this User Service. 

NOTE: The User Service Discovery / Announcement procedures are specified in TS 26.346 [13]. It is out of the 
scope of the present specification how the UE receives the User Service information and how the User 
Service is triggered in the UE. 

The UE shall receive the following information via the User Service Discovery / Announcement procedures: 

Fully qualified domain name of the key management server (i.e. the BM-SC). This for the UE to know to which 
IP address to send the MSK request. 

Confidentiality protection: on / off. 

Integrity protection: on / off. 

UICC key management required: yes/ no. 

Identifiers of the MSKs needed for the User Service. 

The Key Number part of the MSK ID(s) shall be set to 0x0 to denote the current MSK. Specific Key Number 
values are not used since they may change over time and Key Group part of MSK ID is sufficient to identify the 
MSKs, see clause 6.3.2.1. 

Mapping information how the MSKs are used to protect the different User Service Sessions. 

Editors' Note: The exact syntax of the service announcement information including security parameters, e.g. possible 
XML schema of the parameters and its MIME type are to be specified in SA4. 
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UE 



User Service Discovery / BM-SC 
Announcement (security parameters) 



HTTP POST (List of MSK IDs) 

HTTP 401 WWW-Authenticate 
(digest challenge) 



HTTP POST Authorization request 
(digest response) (List of MSK IDs) 



HTTP 200 OK Authentication-Info 



MIKEY(MSK)/UDP 



MIKEY ACK/UDP 
► 

Figure 6.2a: MSK retrieval procedure 

In case the UICC key management is required, the UE should only try to access the MBMS user service if the used 
UICC application is capable of MBMS key management. 

The communication between the UE and the BM-SC is authenticated and integrity protected with HTTP Digest as 
described in clause 6.2.1 of this specification. 

The UE requests for the MSKs using with the HTTP POST message. 
The rest of the procedure is the same as in clause 6.3.2.3.1. 



6.3.2.2.3 



Missed key update procedure 



When the UE has missed an MSK update and it detects that it has not got the current MSK, e.g. from the received 
traffic, it may trigger the retrieval of the current MSK from the BM-SC. The procedure is the same as the Basic MSK 
Retrieval procedure in clause 6.3.2.3.1. 



6.3.2.2.4 



BM-SC solicited pull 



While the push is the regular way of updating the MSK to the UE, there may be situations where the BM-SC solicits the 
UE to contact the BM-SC and request for new MSK. An example of such a situation is when the BM-SC wants the UE 
to trigger a UE that it needs to update the MSK. 
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UE BM-SC 

MIKEY (Key Number part of MSK ID = 0x0) with last MUK 
■1 
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| by BM-SC. Run GBA if that MUK was 

j expired and no valid GBA-key is present. j 



HTTP POST (MSK ID) 
► 



■4 


HTTP 401 WWW -Authenticate 
(digest challenge) 






HTTP POST Authorization request 
(digest response) (MSK ID) 




w 




HTTP 200 OK Authentication- Info 




< — 


MIKEY (MSK) / UDP 





MIKEY ACK / UDP 
► 



Figure 6.2b: BM-SC solicited pull 

The BM-SC sends a MIKEY message over UDP to the UE. The MIKEY message shall be protected by the most recent 
MUK known by the BM-SC. The Key Number part of the MSK ID in the extension payload of the MIKEY message 
shall be set to 0x0 to indicate that the UE should request for current MSK from the BM-SC. 

NOTE 1: A MUK may be used by the BM-SC beyond the GBA key lifetime of the corresponding Ks_xx_NAF for 
the purpose of using the MUK within the first MIKEY message of a push solicited pull procedure. 

NOTE 2: Since the integrity of the MIKEY message still needs to be assured, a KEMAC payload shall be included 
in the MIKEY message from the BM-SC. There is however no key present in the message. Thus by 
setting the Encr data len field to zero, only the MAC of the message will be included. 

When receiving the message, the UE shall request for the current MSK for the specified Key Group. The BM-SC may 
trigger re-authentication of the UE or even re-run of GBA procedure to update the MUK as is described in 
TS 33.220 [6]. 

The rest of the procedure is the same as in clause 6.3.2.3.1. 
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6.3.2.3 MSK push procedures 
6.3.2.3.1 Pushing the MSKs to the UE 

The BM-SC controls when the MSKs used in a multicast service are to be changed. The below flow describes how 
MSK changes are performed. 

UE BM-SC 

MIKEY (MSK ) / UDP 



•4- 



MIKEY ACK / UDP 



Figure 6.3: Pushing the MSKs to the UE 

When the BM-SC decides that it is time to update the MSK, the BM-SC sends MIKEY message over UDP transporting 
the requested MSKs to the UE. 

If requested by the BM-SC, the UE sends a MIKEY acknowledgement message to the BM-SC. 

6.3.2.3.2 Void 



6.3.3 MTK procedures 

6.3.3.1 MTK identification 

Every MTK is uniquely identifiable by its Key Domain ID, MSK ID and MTK ID 
where 

Key Domain ID, and MSK ID are as defined in clause 6.3.2.1. 

MTK ID is 2 bytes long sequence number and is used to distinguish MTKs that have the same Network ID, Key 
Group ID and MSK ID. It is carried in the MTK-ID field of MIKEY extension payload. The MTK ID shall be 
increased every time the MTK is updated. The MTK ID shall be reset every time the MSK is updated. 

6.3.3.2 MTK update procedure 

The MTK is delivered to the UE as in 6.3.2.3.1 but the MIKEY ACK is not used. 



6.3.3.2.1 MTK delivery in download 

In the download case the MIKEY message carrying the MTK shall be delivered over the same FLUTE stream as the 
object to be downloaded to the UE (see TS 26.346 [13]). This means that the message is specified as a separate object in 
the FLUTE File Delivery Table (FDT), having its own identifier. The mime-type of the object carrying the MIKEY 
message shall be the IANA-registered type for MIKEY. 

6.3.3.2.12 MTK delivery in streaming 

MIKEY messages transporting MTKs shall be sent using the same IP address as the RTP traffic. MIKEY messages 
shall be transported to UDP port number specified for MIKEY. 

Editor's Note: The UDP port number needs to be specified for MIKEY. 



ETSI 



3GPP TS 33.246 version 6.1.0 Release 6 



17 



ETSI TS 133 246 V6.1.0 (2004-12) 



6.4 MIKEY message creation and processing in the ME 

Editor's note: The need for salting keys in processing of MIKEY messages is for further study. 

6.4.1 General 

MIKEY is used to transport the MSKs and MTKs from the BM-SC to the UE. Clauses 6.4.2, 6.4.3, 6.4.4 and 6.4.5 
describe how to create the MIKEY messages, while clause 6.4.6 describes the initial processing by the ME on these 
messages. The final processing is done by the MBMS key Generation and Validation Function (MGV-F) and is 
described in clause 6.5. 

MIKEY shall be used with pre-shared keys as described in RFC 3830 [9]. 

To keep track of MSKs and MTKs, a new Extension Payload (EXT) [16] is added to MIKEY. The Extension Payload 
can contain the key types and identities of MSK and the MTK and Key Domain ID (see clauses 6.3.2 and 6.3.3). 

6.4.2 MIKEY common header 

MSKs shall be carried in MIKEY messages. The messages are sent point-to-point between the BM-SC and each UE. 
The messages use the MUK shared between the BM-SC and the UE as the pre-shared secret in MIKEY. 

Once the MSK is in place in the UE, the UE can make use of the multicast MTK messages sent by the BM-SC. The 
MTK is carried in messages conforming to the structure defined by MIKEY and use the MSK as the pre-shared secret. 

If the BM-SC requires an ACK for an MSK key update message this is indicated by setting the V-bit in the MIKEY 
common header. The UE shall then respond with a MIKEY message containing the verification payload. In the case the 
server does not receive an ACK, normal reliability constructions can be used, e.g., start a timer when the message is 
sent and then resend the message if no ACK is received before the timer expires. 

The CSB ID field of MIKEY common header is not used. 

6.4.3 Replay protection 

Each MIKEY message contains the timestamp field (TS) of type 2. This means that the contents of the timestamp field 
is a 32-bit counter. The counter is increased by one for each message sent from the BM-SC to the UE. Note that there is 
one counter per UE for MSK delivery, and one counter common to all UEs for MTK delivery. The counter is used for 
replay protection; messages with a counter less than or equal to the current counter are discarded. Less than or equal is 
to be taken in the meaning of RFC1982. If the less than or equal relation is undefined in the sense of RFC1982, the 
message should be considered as being replayed and shall be discarded. The counter in the TS field shall be reset for 
MSK transport messages when the MUK is updated. The counter in the TS field shall be reset for MTK transport 
messages when the MSK is updated. 

NOTE: The counter in TS field in MTK transport messages is used to detect replay attacks while the counter in 
MTK ID field of the EXT payload is used to detect the resendings of the same MTK keys. 

6.4.4 General extension payload 

The MSK and MTK shall be delivered in messages that conform to the structure defined in RFC 3830 [9] (MIKEY). To 
be able to keep track of the key that is derived in the message, a general Extension Payload (EXT) with Type field value 
x is used that conforms to the structure defined in reference [16]. 

Editor's Note: The type value will be replaced by value requested from IAN A. 

The EXT includes a Key Domain ID and one or two Key Type ID sub-payloads depending on the message. These are 
used as follows. 

For MSK delivery the EXT includes the Key Domain ID and a Key Type ID sub-payload. The Key Domain ID has the 
value as specified in clause 6.3.2.1. The Key Type ID sub-payload includes the type and ID of the key that is delivered 
in the message, i.e. the MSK ID, see figure 6.4a. The key that is used to protect the message, i.e. MUK, is identified as 
specified in clause 6.1. 
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For MTK delivery the EXT includes the Key Domain ID and two Key Type ID sub-payloads. The Key Domain ID has 
the value as specified in clause 6.3.2.1. The first Key Type ID sub-payload includes the type and ID of the key that is 
used to protect the message, i.e. the MSK ID, and the second Key Type ID sub-payload includes the type and ID of the 
key that is delivered in the message, i.e. the MTK ID, see figure 6.4b. 

Editor's Note: The Key Domain ID needs to be added to [16]. It may need an extension payload type of its own. 

See. clauses 6.3.2.1 and 6.3.3.1 for definition of MSK ID and MTK ID. The MTK ID is increased every time the 
corresponding key is updated. It is possible that the same MTK is delivered several times in multicast, and the ME can 
then discard messages related to a key it already has instead of passing them to the MGV-F. 

The MGV-F (see clause 6.5) protects itself from a possibly malicious ME by checking the integrity and freshness of the 
MIKEY message. 

The format of the key IDs shall be represented by unsigned integers, different from zero. The reason for disallowing 
zero is that it is reserved for future use. Note that this means that there can only be 2 n - 1 different keys in use during the 
same session, where n is the number of bits in the ID field. 



Key Domain ID 



Key Type ID sub-payload (MSK ID) 



Figure 6.4a: Extension payload used with MIKEY MSK message 



Key Domain ID 



Key Type ID sub-payload (MSK ID) 



Key Type ID sub-payload (MTK ID) 



Figure 6.b: Extension payload used with MIKEY MTK message 

6.4.5 MIKEY message structure 
6.4.5.1 MSK message structure 

The structure of the MIKEY message carrying a MSK key is depicted in Figure 6.5. The actual key that is delivered is 
kept in the KEMAC payload. The MIKEY-RAND is used to derive e.g. encryption and authentication keys from the 
received keys. It is sent in all the MSK delivery messages. The identity payloads of the initiator's and responder's IDs 
shall be included in the MSK transport messages. IDi is the ID of the BM-SC (i.e. NAF-ID) and IDr is the ID of the 
UE's username (i.e.B-TID). Security Policy (SP) payload includes information for the security protocol such as 
algorithms to use, key lengths, initial values for algorithms etc. The Key Validity Data subfield is present in the 
KEMAC payload when MSK is transported but it is not present for MTK transport. The field defines the Key Validity 
Time for MSK in terms of sequence number interval (i.e. lower limit of MTK ID and upper limit of MTK ID). The 
lower limit of the interval defines the SEQs to be used by the MGV-F (see clause 6.5). 

Editor's Note: The contents of the Security Policy payload depends on the used security protocols. RFC 3830 [9] 
(MIKEY) has defined Security Policy payload for SRTP, but for other security protocols there is a need 
to define new Security Policy payloads. The exact definitions of these are FFS. 
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Figure 6.5: The logical structure of the MIKEY message used to deliver MSK. 
For use of brackets, cf. section 1 .3 of RFC 3830 [9] (MIKEY) 

6.4.5.2 MSK Verification message 

If the BM-SC expects a response to the MSK-transport message (i.e., the V-bit in the MIKEY common header is equal 
to 1), the UE shall send a verification message as a response. The verification message shall be constructed according to 
section 3.1 of MIKEY, and shall consist of the following fields: HDR II TS II IDr II V, where IDr is the ID of the UE. 
Note that the MAC included in the verification payload, shall be computed over both the initiator's and the responder's 
ID as well as the timestamp in addition to be computed over the response message as defined in RFC 3830 [9]. The key 
used in the MAC computation is the MUK_I. 



Common HDR 

TS 

IDr 
V 



Figure 6.6: The logical structure of the MIKEY Verification message 

The verification message shall not be sent as a response to MIKEY messages delivering MTK. 

The verification message shall be constructed by the ME, except for the MAC field, and then be given to the MGV-F 
that will perform the MAC computation and will return the verification message appended with the MAC to the ME. 
The ME shall send the message to the BM-SC. 

6.4.5.3 MTK message structure 

The structure of the MIKEY message carrying a MTK key is depicted in Figure 6.7. The actual key that is delivered is 
kept in the KEMAC payload. If MTK is to be used for streaming protection, then a 1 12 bit salt shall be added to the 
KEMAC payload in addition to the MTK. The network identity payloads (IDi) shall be used in MTK transport 
messages. 



Common HDR 

TS 

IDi 

EXT 
KEMAC 



Figure 6.7: The logical structure of the MIKEY message used to deliver MTK 



ETSI 



3GPP TS 33.246 version 6.1.0 Release 6 



20 



ETSI TS 133 246 V6.1.0 (2004-12) 



6.4.6 Processing of received messages in the ME 

6.4.6.1 MSK MIKEY Message Reception 

When the MIKEY message arrives at the ME, the processing proceeds following the steps below (basically following 
section 5.3 of RFC 3830 [9]). 

1 . The Extension Payload (EXT) is examined, and if it indicates an MSK delivery protected with MUK, the MUK 
ID is received by combining IDi and IDr. 

2. The Timestamp Payload is checked, and the message is discarded if the counter in the Timestamp Payload is 
smaller or equal to the stored replay counter associated with the given MUK (the stored replay counter value is 
retrieved from MGV-S). To avoid issues with wrap around of the ID fields "smaller than" should be in the sense 
of RFC 1982 [10]. 

3. The Security Policy payload is stored if it was present. 

4. The message is transported to MGV-F for further processing, cf clause 6.5.2. 

5. The MGV-F replies success or failure. 

6.4.6.2 MTK MIKEY Message Reception 

When the MIKEY message arrives at the ME, the processing proceeds following the steps below (basically following 
section 5.3 of RFC 3830 [9]). 

1. The Extension Payload (EXT) is examined, and if it indicates an MTK delivery protected with MSK, the MSK 
ID is extracted from the Extension Payload. 

2. The Timestamp Payload is checked, and the message is discarded if the counter in the Timestamp Payload is 
smaller or equal to the stored replay counter associated with the given MSK (the stored replay counter value is 
retrieved from MGV-S). To avoid issues with wrap around of the ID fields "smaller than" should be in the 
sense of RFC 1982 [10]. 

3. If the MTK ID extracted from the Extension payload is less than or equal to the current MTK ID (kept in the 
ME), the message shall be discarded. 

4. The message is transported to MGV-F for further processing, cf 6.5.3. 

5. The MGV-F replies success (i.e. sending the MTK and salt if available) or failure. 

6.5 Validation and key derivation functions in MGV-F 

6.5.1 General 

It is assumed that the UE includes a secure storage (MGV-S). This MGV-S may be realized on the ME or on the UICC 
but for certain type of MBMS services the UICC shall be used as determined by the service provider. The MGV-F is 
implemented inside MGV-S. 

Editor's Note: The choice between MIKEY key derivation algorithms and other suitable key derivations has not 
been made as there could be algorithms already in the UE. 

6.5.2 MUK derivation 

When a MUK has been installed in the MGV-S, i.e. as a result of a GBA run, it is used as pre-shared secret used to 
verify the integrity of the MSK transport message and decrypt the key carried in the KEMAC payload as described in 
RFC 3830 [9]. 
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6.5.3 MSK processing 

When the MGV-F receives the MIKEY message, it first determines the type of message by reading the EXT. If the key 
in the message is an MSK protected by MUK, MGV-F retrieves the MUK identified as specified in clause 6.1. 

The integrity of the message is validated and the MSK is extracted from the KEMAC payload as described in section 5 
of reference [9] if the validation is successful. The Key Validity data is extracted from the message and stored (in the 
form of MTK ID interval). The lower limit of the interval defines the SEQs. 

NOTE: The MSK is not necessarily updated in the message, since a MSK transport message can be sent e.g. to 
update the Key Validity data. 

If message validation is successful, then the MGV-F shall update in MGV-S the counter value in the Time Stamp 
payload associated with the corresponding MUK ID. 

6.5.4 MTK processing 

When the MGV-F receives the MIKEY message, it first determines the type of message by reading the EXT. If the key 
inside the message is an MTK protected by MSK, MGV-F retrieves the MSK with the ID given by the Extension 
payload. 

It is assumed that the MBMS service specific data, MSK and the sequence number SEQs, have been stored within a 
secure storage (MGV-S). Both MSK and SEQs were transferred to the MGV-S with the execution of the MSK update 
procedures. The initial value of SEQs is determined by the service provider. 

The MGV-F shall only calculate and deliver the MBMS Traffic Keys (MTK) to the ME if the ptm-key information is 
deemed to be fresh. 

The MGV-F shall compare the received SEQp, i.e. MTK ID from the MIKEY message with the stored SEQs. If SEQp 
is equal or lower than SEQs then the MGV-F shall indicate a failure to the ME. If SEQp is greater than SEQs then the 
MGV-F shall verify the integrity of the MIKEY message according to RFC 3830 [9]. If the verification is unsuccessful, 
then the MGV-F will indicate a failure to the ME. If the verification is successful, then the MGV-F shall update SEQs 
with SEQp value and extract the MTK from the message. The MGV-F then provides the MTK to the ME. 

If MAC verification is successful, the MGV-F shall update in MGV-S the counter value in the Time Stamp payload 
associated with the corresponding MSK ID. 

In the case of streaming, SRTP requires a master key and a master salt. The MTK is used as master key, and the salt in 
the KEMAC payload is used as master salt. 

NOTE: MIKEY includes functionality to derive further keys from MTK if needed by the security protocol. The 
key derivation is defined in section 4.1.3 of RFC 3830 [9] (MIKEY). 

In case of download service, MIKEY key derivation as defined in section 4. 1.3 of MIKEY [9] shall be used to derive 
MTK authentication and encryption keys from MTK in the ME. These keys shall be provided to the download 
protection protocol. 

6.6 Protection of the transmitted traffic 
6.6.1 General 

The data transmitted to the UEs is protected by a symmetric key (an MTK) that is shared by the BM-SC and UEs that 
are accessing the MBMS service. The protection of the data is applied by the BM-SC. In order to determine which key 
was used to protect the data key identification information is included with the protected data. The key identification 
information will uniquely identify the MSK and MTK. The MTK is processed according to the methods described in 
clauses 6.4 and 6.5. Whenever data from an MBMS User Service has been decrypted, if it is to be stored on the UE it 
will be stored decrypted. 

NOTE: Including the key identification information with the protected data stops the UE trying to decrypt and 
render content for which it does not have the MSK. 
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6.6.2 Protection of streaming data 

6.6.2.1 Usage of SRTP 

When it is required to protect MBMS streaming data SRTP (Secure Real-time Transport Protocol) as defined in 
RFC 371 1 [1 1] shall be used. The MTK is earned to the UEs from the BM-SC using RFC 3830 [9] (MIKEY) with 
extensions defined according to this specification. MTK shall be used as the master key in SRTP key derivation to 
derive the SRTP session keys as defined in section 4.3 of RFC 3830 [9]. The correct MTK to use to decrypt the data is 
indicated using the MKI (Master Key identifier) field, which is included in the SRTP packets as defined in 
RFC 371 1 [1 1]. The form of MKI shall be a concatenation of MSK ID and MTK ID, i.e. MKI = (MSK ID II MTK ID). 

If the SRTP packets are to be integrity protected, the SRTP authentication tag is appended to the packets as defined in 
RFC 3830 [9]. 

SRTP security policy parameters, such as encryption algorithm, are transported in MIKEY Security Policy payload as 
defined in section 6.10.1 in RFC 3830 [9]. 

6.6.2.2 Packet processing in the UE 

When the SRTP module receives a packet, it will retrieve the correct cryptographic context identified by destination 
transport address, destination port and SSRC (according to RFC 371 1 [11]), check if it has the MTK corresponding to 
the value in the MKI field in the SRTP cryptographic context. 

NOTE 1 : The cryptographic context needs to be unique for each SRTP stream. 

NOTE 2: The SRTP module does not need to interpret the MKI field semantics. It only checks whether it has the 
MTK corresponding to the MKI value. 

If the check is successful, the SRTP module processes the packet according to the security policy. 

If the SRTP module does not have the MTK, it will request the MTK corresponding to the MKI from the key 
management module. When the key management module returns a new MTK, the SRTP module will derive new 
session keys from the MTK and process the packet. However, if the key management module does not have the MSK 
indicated by MKI, then it should fetch the MSK using the methods discussed in the clause 6.3. 

If the correct MTK is not present in the UE when RTP traffic arrives, the UE shall wait for the next MTK update 
procedure from the BM-SC as described in clause 6.3.3.2. 

NOTE 3: It is implementation specific issue whether the UE spools encrypted packets or discards all packets before 
the UE has received the correct MTK. 

If the SRTP module has lost synchronisation on the ROC (Roll-over counter) of the SRTP stream, it shall wait for the 
next MTK update message received within the ptm stream. The BM-SC shall deliver the current ROC-value within the 
CS ID map info payload of the MIKEY common header payload. 

The below flow shows how the protected content is delivered to the UE. 



UE BM-SC 

SRTP packet (MKI, auth tag) 

< 

Figure 6.8: Delivery of protected streaming content to the UE 

6.6.3 Protection of download content 

Editor's Note: The details of MBMS download protection are subject to the response from OMA B AC DLDRM. 
SA3 has asked OMA BAC DLDRM whether it is possible to include the extensions and deviations 
needed for using the DCF format for MBMS download protection to OMA DRM v2.0 DCF specification. 
If the answer is positive, some material in this section will be removed and the OMA specification 
referenced instead. 
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6.6.3.1 



General 



Data that belongs to a download MBMS User Service is decrypted as soon as possible by the UE, if the MSK needed to 
provide the relevant MTK is already available on the UE. 



When it is required to protect MBMS download content, OMA DRM V2.0 DCF as defined in reference [15] shall be 
used. MBMS download contents are indicated by the 3GPP-MBMS-DCF flag in the Common Headers Box of a DCF. 
OMA DRM Rights Objects are not utilized. Instead, encryption and authentication keys are generated from MTK. For 
integrity protection, an MBMSSignature as specified below is attached in the FreeSpaceBox of the DCF. 

The MBMSSignature Box is an extension to OMA DRM V2.0 DCF for use by MBMS, and is defined as follows: 

aligned (8) class MBMSSignature extends Fullbox ( 'sign' , version, flags) { 
Unsigned int(8) SignatureMethod; // Signature Method 
Char Signature []; // Actual Signature 



SignatureMethod Field: 
NULL 0x00 
HMAC-SHA1 0x01 

The range of data for the HMAC calculation shall be according to section 5.3 of reference [15]. 

The correct MTK for decrypting and verifying the integrity of the download content is indicated by the key_id in the 
RightsIssuerURL field as follows: 

mbms-key://key_id 

where key_id is defined as the base64 encoded concatenation (Key Domain ID II MSK_ID II MTK ID). 

In case the FDT of the FLUTE protocol needs to be protected, the FDT may also be wrapped in a different DCF. 
Confidentiality and/or integrity protection of FDT can be provided this way. 

Editors' note: The optionality of FDT protection is still under study (i.e. whether it should be mandated). 



6.6.3.2 



Usage of OMA DRM DCF 
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Annex A (informative): 
Trust model 

The following trust relationship between the roles that are participating in MBMS services are proposed: 

- the user trusts the home network operator to provide the MBMS service according to the service level 
agreement; 

the user trusts the network operator after mutual authentication; 

- the network trusts an authenticated user using integrity protection and encryption at RAN level; 

- the network may have trust or no trust in a content provider. 

The home network and visited network trust each other when a roaming agreement is defined, in the case the user is 
roaming in a VPLMN. 
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Annex B (informative): 
Security threats 

B.1 Threats associated with attacks on the radio interface 

The threats associated with attacks on the radio interface are split into the following categories, which are described in 
the following clauses: 

- unauthorized access to multicast data; 

- threats to integrity; 

- denial of service; 

- unauthorized access to MBMS services; 

- privacy violation. 

The attacks on the MBMS service announcements to the users on the radio interface are not discussed here, as these will 
most likely be transferred on a point-to-point connection (e.g. PS signaling connection), which is already secured today 
(integrity protected and optionally encrypted RAN level). 

B.1 .1 Unauthorised access to multicast data 

Al: Intruders may eavesdrop MBMS multicast data on the air-interface. 

A2: Users that have not joined and activated a MBMS multicast service receiving that service without being 

charged. 

A3: Users that have joined and then left a MBMS multicast service continuing to receive the MBMS multicast 

service without being charged. 

A4: Valid subscribers may derive decryption keys (MTK) and distribute them to unauthorized parties. 

NOTE: It is assumed that the legitimate end user has a motivation to defeat the system and distribute the shared 
keys (MSK, MTK) that are a necessary feature of any broadcast security scheme. 

B.1 .2 Threats to integrity 

Bl: Modifications and replay of messages in a way to fool the user of the content from the actual source, e.g. 

replace the actual content with a fake one. 

B.1 .3 Denial of service attacks 

Cl: Jamming of radio resources. Deliberate manipulation of the data to disturb the communication. 

B.1 .4 Unauthorised access to MBMS services 

Dl: An attacker using the 3GPP network to gain "free access" of MBMS services and other services on 

another user's bill. 

D2: An attacker using MBMS shared keys (MSK, MTK) to gain free access to content without any knowledge 
of the service provider. 
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NOTE: It cannot be assumed that keys held in a terminal are secure. No matter how the shared keys (MSK, MTK) 
are delivered to the terminal, we have to assume they can be derived in an attack. For example, the shared 
keys, while secure in the UICC, may be passed over an insecure SIM-ME interface. 



B.1.5 Privacy violation 

El: The user identity could be exposed to the content provider, in the case the content provider is located in 

the 3GPP network, and then linked to the content. 



B.2 Threats associated with attacks on other parts of the 
system 

The threats associated with attacks on other parts of the system are split into the following categories, which are 
described in the following clauses: 

unauthorized access to data; 

- threats to integrity; 

- denial of service; 

- A malicious UE generating MTKs for malicious use later on; 

- Unauthorized insertion of MBMS user data and key management data. 



B.2.1 Unauthorised access to data 

Fl: It is assumed that the BM-SC and the GGSN are located in the same network. The BM-SC can though be 

located in a different place than the GGSN, and therefore can open up for intruders who may eavesdrop 
the new interface Gi and Gmb between the BM-SC and GGSN. 

F2: Intruders may eavesdrop the new interface between the content provider and the BM-SC. 



B.2. 2 Threats to integrity 



Gl: It is assumed that the BM-SC and the GGSN are located in the same network. The BM-SC can though be 
located in a different place than the GGSN, and therefore can open up for new attacks on the new 
interfaces Gi and Gmb between the BM-SC and GGSN. 

G2: The new interface between the content provider and the BM-SC may open up for attacks as modifications 
of multimedia content. 



B.2. 3 Denial of service 

HI: Deliberated manipulation of the data between the BM-SC <-> Content Provider to disturb the 
communication. 

H2: Deliberated manipulation of the data between the BM-SC <-> GGSN to disturb the communication. 



B.2. 4 A malicious UE generating MTKs for malicious use later on 

II: A malicious ME querying the MTK generation function for MTK's to use them later on in an attack (e.g. 

in order to use the retrieved MTKs within an unauthorized data insertion attacks (See B.2. 5)). 
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B.2.5 Unauthorised insertion of MBMS user data and key 
management data 

Jl: An ME, which deliberately inserts key management and malicious data, encrypted with valid (previously 

retrieved) MTK from the MTK generation function, within the multicast stream. 

J2: An ME, which deliberately inserts key management and malicious data, encrypted with old (using 

replayed key management messages) MTK, within the multicast stream. 

J3: An attacker, which deliberately inserts incorrect key management information within the multicast stream 

to cause Denial of Service attacks. 
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Annex C (normative): 
Multicast security requirements 

C.1 Requirements on security service access 
C.1 .1 Requirements on secure service access 

Rla: A valid USIM shall be required to access MBMS User Services. 

Rib: It shall be possible to prevent intruders from obtaining unauthorized access of MBMS User Services by 
masquerading as authorized users. 

C.1 .2 Requirements on secure service provision 

R2a: It shall be possible for the network (e.g. BM-SC) to authenticate users at the start of, and during, service 
delivery to prevent intruders from obtaining unauthorized access to MBMS User Services. 

R2b: It shall be possible to prevent the use of a particular USIM to access MBMS User Services. 

NOTE: No security requirements shall be placed on the UE that requires UE to be customised to a particular 
customer prior to the point of sale. 



C.2 Requirements on MBMS transport Service signaling 
protection 

R3a: It shall be possible to protect against unauthorized modification, insertion, replay or deletion of MBMS 
transport service signaling on the Gmb reference point. 

NOTE 1 : This requirement may be fulfilled by physical or proprietary security measures if the Gmb protocol 
endpoints (i.e. GGSN, Gmb-Proxy and BM-SC) are located within the same security domain of the 
operator's network. Otherwise the security mechanisms as specified within TS 33.210 [14] shall be 
applied. 

R3b: Unauthorized modification, insertion, replay or deletion of all transport service signaling, on the RAN 
shall be prevented when the RAN selects a point-to -multipoint (ptm) link for the distribution of MBMS 
data to the UE. 

NOTE 2: UTRAN Bearer signalling integrity protection will not be provided for point to multipoint MBMS 

signalling and GERAN has no bearer signalling integrity protection, even for point to point signalling. 



C.3 Requirements on Privacy 

R4a: The User identity should not be exposed to the content provider or linked to the content in the case the 
Content Provider is located outside the 3GPP operator's network. 

R4b: MBMS identity and control information shall not be exposed when the RAN selects a point-to-multipoint 
link for the distribution of MBMS data to the UE. 

NOTE: UTRAN and GERAN Bearer confidentiality protection will be not be provided for point to multipoint 
MBMS sessions. 
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C.4 Requirements on MBMS Key Management 

R5a: The transfer of the MBMS keys between the MBMS key generator and the UE shall be confidentiality 
protected. 

R5b: The transfer of the MBMS keys between the MBMS key generator and the UE shall be integrity 
protected. 

R5c: The UE and MBMS key generator shall support the operator to perform re-keying as frequently as it 
believes necessary to ensure that: 

- users that have joined an MBMS User Service multicast service, but then left, shall not gain further 
access to the MBMS User Service without being charged appropriately 

users joining an MBMS User Service shall not gain access to data from previous transmissions in the 
MBMS User Service without having been charged appropriately 

- the effect of subscribed users distributing decryption keys to non-subscribed users shall be 
controllable. 

R5d: Only authorized users that have joined an MBMS User Service shall be able to receive MBMS keys 
delivered from the MBMS key generator. 

R5e: The MBMS keys shall not allow the BM-SC to infer any information about used UE-keys at radio level 
(i.e. if they would be derived from it). 

R5f: All keys used for the MBMS User Service shall be uniquely identifiable. The identity may be used by the 
UE to retrieve the actual key (based on identity match, and mismatch recognition) when an update was 
missed or was erroneous/incomplete. 

R5g: The BM-SC shall be aware of where all MBMS specific keys are stored in the UE (i.e. ME or UICC). 

R5h: The function of providing MTK to the ME shall only deliver a MTK to the ME if the input values used 
for obtaining the MTK were fresh (have not been replayed) and came from a trusted source. 



C.5 Requirements on integrity protection of MBMS User 
Service data 

R6a: It shall be possible to protect against unauthorized modification, insertion, replay or deletion of MBMS 
User Service data sent to the UE on the radio interface. The use of integrity shall be optional. 

NOTE: It may be possible to detect the deletion of MBMS data packets, but it is impossible to prevent the 

deletion. Packets may be lost because of bad radio conditions, providing integrity protection will not help 
to detect or recover from this situation. 

NOTE: The use of shared keys (integrity and confidentiality) to a group of untrusted users only prevents attacks 
of lower levels of sophistication, such as preventing eavesdroppers from simply listening in 

R6b: The MBMS User Service data may be integrity protected with a common integrity key, which shall be 
available to all users that have joined the MBMS User Service. 



R6c: It may be required to integrity protect the "BM-SC - GGSN" interface i.e. reference point Gi. 
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C.6 Requirements on confidentiality protection of MBMS 
User Service data 

R7a: It shall be possible to protect the confidentiality of MBMS User Service data on the radio interface. 

R7b: The MBMS User Service data may be encrypted with common encryption keys, which shall be available 
to all users that have joined the MBMS User Service. 

R7c: It may be required to encrypt the MBMS User Service data on the "BM-SC - GGSN" interface, i.e. the 
reference points Gi. 

R7d: It shall be infeasible for a man-in-the-middle to bid down the confidentiality protection used on protect 
the MBMS User Service from the BM-SC to the UE. 

R7e: It shall be infeasible for an eavesdropper to break the confidentiality protection of the MBMS User 
Service when it is applied. 



C.7 Requirements on content provider to BM-SC 
reference point 

R8a: The BM-SC shall be able to authenticate and authorize a 3 rd party content provider that wishes to transmit 
data to the BM-SC. 

R8b: It shall be possible to integrity and confidentiality protect data sent from a 3 rd party content provider to 
the BM-SC. 

NOTE: This reference point will not be standardised. 
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Annex D (normative): 
UICC-ME interface 

D.1 MSK Update Procedure 

This procedure is part of the MSK update procedure as described in clause 6.5 (Validation and key derivation functions 
in MGV-F). 

The ME has previously performed a GBA_U bootstrapping procedure as described in TS 33.220. The UICC stores the 
corresponding Ks_int_NAF together with the NAF_Id associated with this particular bootstrapping procedure. 

The ME receives a MIKEY message containing an MSK update procedure. After performing some validity checks, the 
ME sends the whole message to the UICC. The UICC uses the MUK ID (included in the MIKEY message, see 
clause 6.1) to identify the stored Ks_int_NAF. 

The UICC then uses Ks_int_NAF as the MUK value for MUK derivation and MSK validation and derivation (as 
described in clause 6.5.3). 

After successful MSK Update procedure the UICC stores the Key Domain ID, MSK ID, MSK and MSK Validity Time 
(in the form of MTK ID interval). 

UICC ME 

MBMS Procedure (MSK Update Mode) 
MIKEY 

< 

Success/Failure 
► 

Figure D.1 : MSK Update Procedure 



D.2 MSK Verification Message Generation 

This procedure is part of the MSK Verification Message as described in clause 6.4.5.2 (MSK Verification message). 

The ME constructs the verification message in response to the MSK-transport message when it is required by BM-SC. 

The ME shall then give the constructed MIKEY verification message, with an empty MAC field, to the UICC and the 
ME shall include NAF_id in this message. The UICC uses the MUK ID (see clause 6.1) to identify the stored 
Ks_int_NAF=MUK to be used in the MSK Verification Message Generation. 

The UICC will verify that the Time Stamp MIKEY field correspond to the previous MSK Update procedure. Then, the 
UICC shall compute and send the MIKEY packet to the ME (including the calculated MAC field) as defined in 
clause 6.4.5.2. (MSK Verification message). 



ETSI 



3GPP TS 33.246 version 6.1.0 Release 6 



32 



ETSI TS 133 246 V6.1 .0 (2004-12) 



UICC ME 

MBMS Procedure (MSK Verification Message) 
NAF_Id II MIKEY 
< 

MIKEY 

► 

Figure D.2: MSK Verification Message 



D.3 MTK generation and validation 

This procedure is part of the MTK generation and validation function as described in clause 6.5.4 (MTK validation and 
derivation). 

The ME receives the MIKEY message (containing Header, Time stamp, Key Domain ID, MSK ID, MTK ID = SEQp, 
MSK_C[MTKIISalt (if salt is available)] and MAC). After performing some validity checks, the ME sends the whole 
message to the UICC. The UICC computes the MGV-F function as described in clause 6.5. (Validation and key 
derivation functions in MGV-F). After successful MGV-F procedure the UICC returns the MTK. 



UICC ME 

MBMS Procedure (MTK traffic Mode) 
MIKEY 

A 

MBMS Procedure response 
MTK II Salt (if available)/ Failure 

Figure D.3: MTK Generation and Validation 
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Annex E (Informative): 

MIKEY features not used in MBMS 

- An MBMS capable ME/UICC and BM-SC do not need to implement the public key encryption method of 
MIKEY (section 3.2 of RFC 3830 [9]) and related payloads, although mentioned in RFC 3830 [9] as mandatory 
for implementation. 

- An MBMS capable ME/UICC and BM-SC do not need to implement the Time Stamp payload types NTP-UTC 
and NTP of MIKEY (section 6.6 of RFC 3830 [9]) although mentioned in RFC 3830 [9] as mandatory for 
implementation. 
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Annex E (informative): 
Change history 
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